I added a new commit with the implementation for the suggestions @fmvilas made here.
I ended up creating an intermediate object for channels, operations, and messages.

cc @jonaslagoni

I think we would also need to introduce methods for getting objects by their ID, like document.channel(<channel_id>), document.operation(<operation_id>), document.server(<server_name>).

Edit: this is covered by document.channels().filterById(), document.operation().filterById(), document.messages().filterById(), document.servers().filterById()

• Added IntentServers object with same style as IntentChannels, IntentOperations, and ` IntentMessages).
• Added a id() method on the following models:
  • Channel -> returns key on the map for 2.x.x
  • Operation -> returns operation id for 2.x.x
  • Message -> returns uid for 2.x.x
  • Server -> returns key on the map for 2.x.x
• Removed document.channel(<channel_name>) method in favor of document.channels().filterById(<name>).

I'm thinking about introducing an isEmpty() method to all those intermediate objects, so we can remove the document.hasChannels-like methods.
The point is that isEmpty is the opposite of what we previously had (emptiness vs fullness) so not sure what others think about.

I'm thinking about introducing an isEmpty() method to all those intermediate objects, so we can remove the document.hasChannels-like methods. The point is that isEmpty is the opposite of what we previously had (emptiness vs fullness) so not sure what others think about.

I think it's a good idea 👍

Operation -> returns operation id for 2.x.x

An operation might not contain an operationId, so it's possible we get undefined. However, in v3, the "operationId" is mandatory (it's implicit), so I wonder if we shouldn't be generating operation ids for those operations that don't have one defined. This way we can make sure we never return undefined in any version.

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

I wonder if we shouldn't be generating operation ids for those operations that don't have one defined. This way we can make sure we never return undefined in any version.

Yeah, I think it makes sense. Would you also suggest we write it as a rule for all parser implementations (Parser-API) ? So the return type should be only string and never empty then.

Would you also suggest we write it as a rule for all parser implementations (Parser-API) ?

I think so. Not sure how far we should get into implementation details other than the API surface but definitely something to take into account. In any case, if we say that operations MUST always have an ID, implementations will have to generate them 😄

@jonaslagoni would you mind converting this issue into a draft? As this is just a POC, I don't think it makes sense to keep it as a regular PR.

This pull request has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this pull request, add a comment with detailed explanation.

There can be many reasons why some specific pull request has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this pull request forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

@jonaslagoni We can close this one as all this work is being done on the next-major branch.